Companies have long sought to integrate existing systems in order to implement information technology (IT) support for business processes that cover all present and prospective systems requirements needed to run the business end-to-end. A variety of designs can be used to this end, ranging from rigid point-to-point electronic data interchange (EDI) interactions to Web auctions. By updating older technologies, such as Internet-enabling EDI-based systems, companies can make their IT systems available to internal or external customers; but the resulting systems have not proven to be flexible enough to meet business demands. A flexible, standardized architecture is required to better support the connection of various applications and the sharing of data. Service Oriented Architecture (SOA) (see DEFINITIONS section) is one such architecture. It unifies business processes by structuring large applications as an ad hoc collection of smaller modules called services.
These applications can be used by different groups of people both inside and outside the company, and new applications built from a mix of services from the global SOA pool exhibit greater flexibility and uniformity. In an example using a bank as the business using the SOA architecture, a bank customer would not, for example, have to provide redundantly the same personal information to open an online checking account, and again for a savings savings, and yet again for an IRA account. This is because the SOA architecture facilitates data transfer, and/or usage of common data, between the three different account opening processes. Furthermore, the interfaces for opening each of the accounts would preferably have the same look and feel and use the same level and type of input data validation. Again, this is facilitated by SOA.
In this way, building all applications from the same SOA pool of services makes the processes: (i) work efficiently from a data standpoint; (ii) work efficiently from a processing standpoint; and (iii) work smoothly from the perspective of customer familiarity and aesthetics. SOA is also more deployable to affiliate companies than other architectures. An example of this, a travel services customer can interact with a rental car company's reservation system from an airline company's reservation system.
Service Oriented Architecture (SOA) is a design framework for realizing rapid and low-cost system development and improving total system quality. SOA preferably uses the Web services standards and technologies and is rapidly becoming a standard approach for enterprise information systems. Web services face significant challenges because of particular requirements. There are many problems that are to be addressed when applying the SOA paradigm to a real-time system, which include response time, support of event-driven, asynchronous parallel applications, complicated human interface support, reliability, etc. As set forth below in the definition of SOA in the DEFINITION section, SOA services communicate with each other. Communication between various SOA services can involve simple data passing, or it can involve two or more services coordinating some activity. Some means of connecting SOA services to each other is generally needed in an SOA system.
SOAs build applications out of software services (see DEFINITIONS section). Because services do not embed calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement.
There were pre-SOA software architectures and/or techniques that promoted some degree of software reuse, specifically: (i) functional software modules and; (ii) predefined groups of functions known as classes. However, these pre SOA software architectures and/or techniques are different than SOA for one or more of the following reasons: (i) they do not use services (see DEFINITIONS section); (ii) the atomic-level objects of an SOA are often 100 to 1,000 times larger; (iii) SOA services are associated by an application designer or engineer using orchestration; and/or (iv) the pre-SOA software architectures and techniques do not otherwise meet the definition of an SOA (see DEFINITIONS section). In the process of orchestration, relatively large chunks of software functionality (services) are associated in a non-hierarchical arrangement (in contrast to a class hierarchy) by a software engineer, or process engineer, using a special software tool which contains an exhaustive list of all of the services, their characteristics, and a means to record the designer's choices which the designer can manage and the software system can consume and use at run-time.
Metadata preferably underlies and enables the SOA. Preferably, the metadata is sufficient to describe not only the characteristics of the SOA services, but also the data that drives them. Extensible markup language (XML) has been used extensively in SOA to create data which is wrapped in a nearly exhaustive description container. Analogously, the services themselves are typically described by web services description language (WSDL), and communications protocols by simple object access protocol (SOAP). Whether these description languages are the best possible for the job, and whether they will remain the favorites going forward, is at present an open question. SOA is preferably dependent on data and services that are described using a type of metadata that will herein be called SOA metadata (see DEFINITIONS section). SOA metadata is metadata in a form so that: (i) software systems can use the SOA metadata to configure themselves dynamically; (ii) software systems can use the SOA metadata to configure themselves by discovery and incorporation of defined services; (iii) coherence is maintained; (iv) integrity is maintained; (v) system designers can understand the SOA metadata at a reasonable cost and effort; and (iv) system designers can manage the SOA metadata at a reasonable cost and effort.
A Component Business Model (CBM) (see DEFINITIONS section) is conventional. For example, US patent application 2005/0246215 (“Rackham”) discloses a methodology for building a CBM. It is conventional for a CBM to include a heat map (see DEFINITIONS section). At FIG. 2C of Rackham, Rackham discloses an example of a heat map. The Rackham CBM and associated heat map are not disclosed to be an approach or tooling to consume a CBM Heat Map for SOA solution development.
US patent application 2007/0279416 (“Cobb”) discloses a computer program product for enabling and rendering business components of a CBM in an interactive data visualization tool. The Cobb product includes one or more heat maps. The CBM and associated heat map(s) of Cobb are not disclosed to be an approach or tooling to consume a CBM Heat Map for SOA solution development.
US patent application 2007/0021993 (“Chandra”) discloses an enterprise architecture that can be viewed through a Component Business Model. In Chandra, a metamodel i integrates the model of the enterprise architecture with the Component Business Model. Chandra does not disclose an approach or tooling to consume a CBM Heat Map for SOA solution development.
US patent application 2007/0033211 (“Berman”) discloses a CBM that provides a logical and comprehensive view of the enterprise, in terms that cut across commercial enterprises and industries. The Berman CBM is based upon a logical partitioning of business activities into non-overlapping managing concepts, at the three levels of management accountability: (i) providing direction to the business; (ii) controlling how the business operates; and (iii) executing the operations of the business. Berman also discloses that merger and acquisition criteria can be used to develop a heat map of components to be included in a divestiture or downsizing. Berman further discloses that a transformation plan includes transformation of technology into a new environment (often moving to a service-oriented architecture or moving data/systems onto newly agreed upon shared platforms). However, Berman does not disclose that the CBM and its associated heat map(s) are located on or implemented by the transformation technology that is planned to be moved to SOA. In other words, Berman does not disclose an approach or tooling to consume a CBM Heat Map for SOA solution development.
US patent application 2007/0038501 (“Lee”) discloses a CBM and an associated heat map. Lee also discloses that the lower layers of its CBM represent IT architecture including a wide range of services implemented in IT infrastructure, such as service-oriented architecture. While the CBM of Lee, in part, represents an SOA, Lee does not disclose an approach or tooling to consume a CBM Heat Map for SOA solution development.
Description Of the Related Art Section Disclaimer: To the extent that specific publications are discussed above in this Description of the Related Art Section, these discussions should not be taken as an admission that the discussed publications (for example, published patents) are prior art for patent law purposes. For example, some or all of the discussed publications may not be sufficiently early in time, may not reflect subject matter developed early enough in time and/or may not be sufficiently enabling so as to amount to prior art for patent law purposes. To the extent that specific publications are discussed above in this Description of the Related Art Section, they are all hereby incorporated by reference into this document in their respective entirety(ies).